A traditional Border Gateway Protocol (simply BGP) defined in the standard of RFC1771, i.e., BGP-4, is only capable of managing route information in a network layer protocol IPv4 but is restricted in terms of propagation across autonomous systems in other network layer protocols, e.g., IPv6, IPX, L3VPN, etc.
(1) Extensions to the BGP-4
As extensions to the BGP-4, the IETF has published the standards of RFC2858 (Multi-protocol Extensions to the BGP-4) and RFC4760 in which a Multi-Protocol-BGP (simply MP-BGP) is defined. The MP-BGP is capable of supporting multiple network protocols, e.g., IPv6, IPX, L3VPN, etc, and is backward compatible, that is, an MP-BGP enabled router may work with a non MP-BGP enabled router.
Among messages used in the BGP-4, three pieces of IPv4 related information are carried in an UPDATE message, i.e., Network Layer Reachability Information (simply NLRI), NEXT-HOP attribute among path attributes (NEXT-HOP) and AGGREGATOR attribute among the path attributes (simply AGGREGATOR).
In an original system base upon the BGP-4 protocol, a path attribute is included in the UPDATE message regardless of whether route information forwarded in the UPDATE message includes the NLRI information or only withdrawn route information. For the MP-BGP, it is considered that next-hop information (provided in the NEXT-HOP attribute) makes sense only when a destination address is reachable or otherwise makes no sense when a destination address is unreachable (i.e., withdrawn). Therefore, an announcement of destination reachability information shall be associated with that of the next-hop information related thereto and isolated from that of the route withdrawn information.
In order to support multiple protocols at the network layer, the BGP-4 shall reflect information of the protocols at the network layer into the NLRI and the NEXT-HOP. The MP-BGP in the RFC2858 has defined two new path attributes, i.e., a Multi-protocol Reachable NLRI (simply MP_REACH_NLRI) attribute and a Multi-protocol Unreachable NLRI (simply MP_UNREACH_NLRI) attribute respectively.
The MP_REACH_NLRI attribute is configured to carry a set of reachable destination information and next-hop information providing forwarding of the reachable destination information.
The MP_UNREACH_NLRI attribute is configured to carry a set of unreachable destination information.
Both of the attributes are optional non-transitive. If a BGP speaker is not capable of supporting multiple protocols, then information with these attributes is simply ignored and will not be passed to another BGP speaker.
The MP_REACH_NLRI attribute, the MP_UNREACH_NLRI attribute, an NLRI encoding process, an error process and the use of a BGP capability advertisement involved in the MP-BGP are detailed below.
(11) The MP_REACH_NLRI attribute is of a type code 14 and is an optional non-transitive attribute used in the following scenarios that: (a) an available route is announced to a neighbor; (b) a router is allowed to announce its network layer address which, like next-hop information, is configured to indicate a destination listed in the field of network layer reachability information of the MP_NLRI attribute. Encoding structures of the MP_REACH_NLRI attribute is illustrated as in FIG. 1. The usages and meanings of respective fields are as follows.
The Address Family Identifier (simply AFI): this field carries the identifier of a connection of a network layer protocol with a network address. The MP-BGP distinguishes different network layer protocols with an address family. With reference to values taken by the address family, reference may be made to the RFC 1700 (see the section of Address Family Numbers). At present, various extended MP-BGP applications have been achieved in a system, including an extension to the IPv6, an extension to the IPX, an extension to the Framework for a Layer 3 Virtual Private network (simply L3VPN), etc., and the different extended applications are configured in their own address family views.
The Subsequent Address Family Identifier (simply SAFI): this field carries supplementary information of the type of Network Layer Reachability Information (NLRI) included in the attribute.
The Length of a Next Hop Network Address: a one-byte field of next-hop address length indicates the length of a next-hop address.
The network Address of Next Hop: this field is variable in length and includes the address of a next router to a destination system.
The network Layer Reachability Information (simply NLRI): this field is variable in length and lists NLRI information of an available route to be announced in the present attribute. When the SAFI is set to be a certain value defined in the standard of RFC4760, all of the NLRI will be subject to an encoding process as specified in the “NLRI encoding”.
Since the MP_REACH_NLRI attribute includes the next-hop information (e.g., the Length of the Next Hop Network Address, the Network Address of the Next Hop, etc.) and the NLRI, the NLRI and the NEXT-HOP attribute in the BGP-4 protocol are not carried directly in the UPDATE message with the MP_REACH_NLRI attribute any longer. If the UPDATE message received in an MP-BGP protocol enabled router includes directly the NEXT-HOP attribute, then the router shall ignore the UPDATE message.
(12) The MP_UNREACH_NLRI attribute is of a type code 15 and is an optional non-transitive attribute used in a scenario where multiple unavailable routes are withdrawn. Encoding structures of the MP_UNREACH_NLRI attribute is illustrated as in FIG. 2. The usages and meanings of respective fields are as follows.
The Address Family Identifier (simply AFI): this field carries the identifier of a network layer protocol related to lower NLRI. At present, this field has a defined value as specified in the RFC1700 (see the section of Address Family Numbers).
The Subsequent Address Family Identifier (simply SAFI): this field carries supplementary information of the type of Network Layer Reachability Information (NLRI) included in the attribute.
The Withdrawn Routes: this field is variable in length and lists NLRI of a route to be withdrawn from a service. When the SAFI is set to be a certain value defined in the RFC4760, each piece of NLRI is subject to an encoding process as specified in the section of “NLRI encoding”.
The UPDATE message with the MP_UNREACH_NLRI attribute is not necessarily carry another patch attribute.
(13) The NLRI encoding process: the network layer reachability information is encoded into one or several sets of two elements similarly as illustrated in FIG. 3. The usages and meanings of respective fields are as follows.
The Length: this field indicates the length of an address prefix in bit. If it is all zero, then this indicates a match to any address.
The Prefix: this field includes an address prefix which is supplemented in bit to a full byte(s) without influencing any true value of the prefix.
(14) The error process: if a BGP speaker receives an UPDATE message with the MP_REACH_NLRI or MP_UNREACH_NLRI attribute from a neighbor and determines that the MP_REACH_NLRI or MP_UNREACH_NLRI attribute in the UPDATE message is incorrect, then the BGP speaker removes all of BGP routes published from the neighbor; if the BGP speaker receives such an UPDATE message in a session duration, then the BGP speaker may ignore all incorrect AFI/SAFI subsequent routes received in the session; further, if the BGP speaker receives such an UPDATE message, then the BGP speaker may terminate a BGP session process. An error process message (e.g., the NOTIFICATION message, etc.) indicates an error code and an error sub-code respectively as “Update Message Error” and “Optional Attribute Error”.
(15) The use of a BGP Capability Advertisement: an MP-BGP enabled BGP speaker shall use a capability advertisement process [BGP-CAP] to test whether the speaker can use a multi-protocol extension method with a specific peer. The capability optional parameter field is configured such that the Capability Code is set to be 1 (indicating a multi-protocol extension capability), the Capability Length is set to be 4, and the Capability value fields include the fields of “AFI”, “Res.” and “SAFI” in sequence.
The AFI field—an address family identifier (16 bits). Encoding way of the AFI field is the same way as that preset in a multi-protocol extension.
The RES. field—a reserved (8-bit) area. It shall be set by a transmitting party as 0 and ignored by a receiving party.
The SAFI field—a subsequent address family identifier (8 bits). Encoding way of the SAFI field is the same as that preset in a multi-protocol extension.
In order to exchange route information for two specific directions between a pair of BGP speakers, each of the BGP speakers shall announce its support for such a special route to the other one through a capability announcement mechanism.
(2) Overview of Extensions to the BGP/MPLS VPN
The standard of RFC2547bis defines a mechanism allowing a service provider to use its own IP backbone and to provide a customer with a Virtual Personal Network (VPN) service. The RFC 2547bis VPN is also referred to as the BGP/MPLS VPN because it uses the BGP to distribute VPN route information over the backbone of the provider and uses Multi-Protocol Label Switching (MPLS) to forward a VPN traffic from one site to another one.
(21) The Structure of an VPN-IPv4 Address
A VPN customer often manages its own network and uses an RFC 1918 private address space. If different VPN customers use the same private IPv4 address, then an address overlap may arise, thus resulting in the difficulty of BGP routing because the BGP assumes that each carried IPv4 address shall be globally unique. In order to address this issue, the BGP/MPLS VPN supports a mechanism through which a non-unique IP address is converted into a globally unique address by using a VPN-IPv4 address family and deploying an extension to the Multi-Protocol-BGP (MP-BGP).
A space of overlapping addresses proposes a challenge that if the traditional BGP sees two different routes for the same IPv4 address prefix (the prefix is assigned to systems in different VPNs), then the BGP will process the prefix as if there were only one route. As a result, there is a VPN system unreachable. In order to address this issue, a mechanism is required to allow the BGP to disambiguate the prefix so that two totally different routes to the address can be deployed, each for respective one of the VPNs. Such a function may be supported in the standard of RFC2547bis by defining a VPN-IPv4 address family.
A VPN-IPv4 address prefix is of 12 bytes in total and includes a 8-byte Route Distinguisher (simply RD) and a 4-byte IPv4 address prefix. A VPN-IPv4 address is structured as including:
a Type Field: 2 bytes; and
a Value Field: 6 bytes
The 8-byte RD is consisted of the 2-byte type field and the 6-byte value field. A value taken by the value field is dependent upon a value of the type field. At present, there are three values of 0, 1 and 2 defined for the type field.
A. When the type filed takes the value of 0, the value field is consisted of two sub-fields:
a manager sub-field: 2 bytes; and
an assigned number sub-field: 4 bytes.
The manager sub-field shall include an Autonomous System Number (ASN), and if this ASN is taken from a public ASN space, then it shall be assigned from an appropriate authority; and the assigned number sub-field includes a number taken from a number space managed by an enterprise to which the ASN specified in the manager sub-field has been assigned from the appropriate authority.
B. When the type filed takes the value of 1, the value field is also consisted of two sub-fields:
a manager sub-field: 4 bytes; and
an assigned number sub-field: 2 bytes.
The manager sub-field shall include an IP address, and if this IP address is taken from a public IP address space, then it shall be assigned from an appropriate authority; and the assigned number sub-field includes a number taken from a number space managed by an enterprise to which the IP address specified in the manager sub-field has been assigned.
C. When the type filed takes the value of 2, two sub-fields are structured as follows:
a manager sub-field: 4 bytes; and
an assigned number sub-field: 2 bytes.
The manager sub-field shall include a 4-byte BGP-AS4 number, and if this ASN is taken from a public ASN space, then it shall be assigned from an appropriate authority; and the assigned number sub-field includes a number taken from a number space managed by an enterprise to which the ASN specified in the manager sub-field has been assigned from the appropriate authority.
Such a structure of the RD ensure that a service provider providing a VPN backbone service can generate a unique RD, but such an RD per se makes no particular sense.
(22) Support of the MP-BGP for the VPN-IPv4
After Virtual Routing Forwarding (VRF) and a Label Switched path (LSP) are set up between PEs, the PEs announce route information respectively to their own BGP peers. When the route information is announced, firstly the IPv4 address prefix of a route is converted into the format of a VPN-IPv4 address prefix with an RD specified when VRF is configured. When the PE announces the route information to the BGP peer, each route (MP-BPG route) shall include the following contents:
1) the VPN-IPv4 address prefix of the route (a 8-byte RD plus a 4-byte IPv4 address prefix);
2) the IP address of the PE per se acts as an MP-BPG next-hop Label Switching Router (LSR) address of the route, and since the MP-BGP requires that next-hop LSR addresses be in the same address format, the MP-BPG next-hop LSR address is in the format of a VPN-IPv4 address with RD=0;
3) a label assigned from the PE to the route;
4) an export Route Target (RT) including VRF of the route, as a “COMMUNITY” attribute of the route; and
5) optionally, the attributes of ORIGIN and AS_PATH are included.
The structure of the VPN-IPv4 address prefix has been described above and is to be encapsulated in the NLRI field of the MP_REACH_NLRI after being encoded.
The NLRI is encoded as in the extended multi-protocol BGP, and the AFI field takes the value of 1 (because the network layer protocol associated with the NLRI is still the IP) to indicate that a VPN-IPv4 address is carried.
Also the MP-BPG route further carries a label which is assigned from a PE to the route and is alike encapsulated in the NLRI field, thereby improving the NLRI encoding format in the RFC2858 by being converted into a set of three elements in the format. As described in the RFC3107 (Carrying Label Information in BPG-4), one or more labels can be carried, each of which has a length of only 3 bytes including upper 20 bits carrying the value of the label and lower 4 bits with three ones being reserved and the last one (S bit) being set to be 1 to indicate arrival at the bottom of a stack of the label (the label here is encoded slightly differently from a standard MPLS label in that no TTL field is included).
When a label is carried in the MP-BPG, the SAFI field of the MP_REACH_NLRI is configured to indicate that the attribute carries “Label” information (the value of the SAFI is set to be 4).
A PE may distribute all of routes present in VRF or may firstly aggregate all these routes and then distribute an aggregation route. Assumed that the PE has assigned a label L to a route R and distributed such a label mapping in the BGP, so when the route R is a route resulting from aggregation of routes in VRF, the PE has to determine how to forward a message by searching for corresponding VRF, where the message carries the label for determining and searching for VRF of the final route, and a label information library reflects the correspondence relationship between the label and VRF; and if R is not an aggregation route, then an export interface and a link layer package type of the message are shown directly in the label information library, and in this case, there is no need to search for VRF. The format of NLRI encoding in the existing VPN-IPv4 protocol is as illustrated in FIG. 4.
The existing MP-BPG protocol supports routing in the protocols of IPv6, IPX, L3VPN, etc., but does not support routing of an E.164 number segment, E.214, an SP code assigned from an enterprise per se, etc., thus failing to perform a function of automatic routing of an E.164, E.124 and SP number.